The Problem:

Contrived example: https://github.com/d4rkr00t/watchpack-infinite-loop-example

In our case, we use monorepo with all of the dependencies in the root node_modules folder which are then symlinked to individual packages, we experience significant performance degradation, because watcher is going very deep through circular symlinks which slows down initial build time, and makes consequent re-builds extremely slow, and the CPU consumption is enormous.

What we've tried:

AFAIK Webpack has 2 ways of ignoring files from watch:

• watchOptions.ignored – they are passed down to chokidar. This one either not working properly in chokidar or I don't understand how it is supposed to work, because whatever I pass through this option isn't helping at all.
• WatchIgnorePlugin – that extends NodeWatchFileSystem. And can filter initial set of files, but DirectoryWatcher using setNestedWatching which adds nested directories to watch and that skips WatchIgnorePlugin.

Temporary solution

We came up with a temporary solution that works for us right now, but it is very hacky. We are monkey patching DirectoryWatcher so it ignores node_modules:

const DirectoryWatcher = require('watchpack/lib/DirectoryWatcher');
const _oldcreateNestedWatcher = DirectoryWatcher.prototype.createNestedWatcher;
DirectoryWatcher.prototype.createNestedWatcher = function(dirPath) {
  if (dirPath.includes('node_modules')) return;
  _oldcreateNestedWatcher.call(this, dirPath);
};

That helped a lot, re-builds now are almost instant, comparing to 30s - 60s before this fix. Though, we are not exactly happy about this solution :)

Proposed solution

What I'm proposing in this PR is that we can use watchOptions.ignored to bail out from watching early. Thus breaking out of the circular symlinks hell. Also it speeds up everything a bit, since watchpack doesn't have to care about ignored folders/files.

Maybe you can suggest better approach for doing this. Or better places where I can add this check.

Also I haven't added any tests yet, since I didn't want to spend time writing them being not sure whether proposed approach is ok for you or not. But if it's fine with you, I'll add tests.

I looked at this PR #41 which potentially can solve this issue, but since it has probably died almost a year ago I think considering other options make total sense.